Today embedded platforms such as mobile phones include support for embedded or removable memory devices connected over well known interfaces like SD (Secure Digital), MMC (Multimedia card), UFS (Unix file system) or SATA (Serial Advanced Technology Attachment) protocol as illustrated in FIG. 1. A host controller 110 is in communication 131 with a memory device 120. The memory device 120 comprises a device controller 122 and a storage medium 121 connected via a bus 132. A memory device 120 includes single or multiple instances of non volatile memory, such as NAND. Each memory instance is split into equal sized NAND blocks and each NAND block is split into NAND pages. The pages are a basic unit of read or write to NAND. Each NAND page is split into MMC blocks (typically 512B). The read or write transfer over SD, MMC or UFS happens in multiples of MMC blocks (also known as just “block” in the SD/MMC specification). The management of these memories is complex since they have limited read or write cycles at every NAND block. An embedded controller within the memory device takes care of the memory management and moves the data around so that read or write are equally distributed across NAND blocks.
To the host controller 110, the embedded controller exposes a “disk like” interface where the host can read or write an MMC block to any location without any restriction. The MMC blocks seen on the “disk like” interface are known as virtual MMC blocks and the embedded controller hides the actual location of the MMC blocks within the device. The embedded controller maintains a mapping table from the virtual MMC block to physical MMC block. On every new write to a virtual MMC block, the embedded controller writes to a free physical MMC block which is written least number of times, marks the previous physical location of the MMC block as dirty and updates the mapping table. The mapping table is part of the meta-data maintained by the embedded controller. In addition to the mapping table, the meta-data also stores a bad block table, wear table. The bad block table contains the block numbers of the bad NAND blocks. The wear table stores the read and write count of every NAND block. The embedded controller also needs to store blocks which are free, used and dirty. Some embedded controllers may derive this information indirectly from the mapping table and some embedded controllers may choose to explicitly store the free blocks, used blocks and dirty blocks in its meta-data. Some embedded controllers may store the meta-data in the spare area of the pages of NAND. Some embedded controllers store the meta-data in separate blocks.
A typical multi block write transfer on eMMC is shown in FIG. 2. At the end of each MMC block (213, 214, 215) write (CMD25), element 211 in FIG. 2, with response 212 (e.g. R1), the mapping table is updated. At the end of the programming (CMD12), element 216 in FIG. 2, with response 217 (e.g. R1), eMMC guarantees the data availability by committing the meta-data write or synchronizes the meta-data 218 to the memory 121 (e.g. in some dedicated NAND blocks). After this point, if host reads back these MMC blocks then embedded controller will fetch the updated content of these MMC blocks.
The overhead of meta-data synchronization is sometimes very significant on a high capacity NAND. On a high capacity NAND, the NAND write could be slower and meta-data could be bigger. This overhead of synchronization becomes significant when small numbers of MMC blocks are transferred in each multi block write and it impacts the write throughput. This problem impacts any embedded storage device such as MMC, SD, UFS and SATA embedding a non-volatile memory such as NAND, NOR, PRAM, PCM. This impacts severely the applications (e.g. data base applications) which continuously updates small amount of data to the embedded memory.
As per POSIX standard, file system layer on host need to guarantee file data synchronization at the non-volatile memory only when the file is closed or when there is explicit user synchronization.
One approach to solving this problem is with large cache on host side and combining small requests to make the overall request size big. But this solution cannot handle situation when the individual write requests are not in contiguous virtual MMC blocks.
The UFS and SATA specifications address cache synchronization but not controlling meta-data synchronization.